Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-labarre-iimc-party-02.txt < prev next >

Wrap

Text File | 1993-06-07 | 112.0 KB | 3,350 lines

INTERNET DRAFT Expires November 29, 1993 ISO/CCITT and Internet Management Coexistence (IIMC): ISO/CCITT to Internet Management Security (IIMCSEC) Draft 2 May 26, 1993 Lee LaBarre (Editor) The MITRE Corporation Burlington Road Bedford, MA 01730 cel@mbunix.mitre.org Status of this Memo This document provides information to the network and systems management community. This document is intended as a contribution to on going work in the area of multi-protocol management coexistence and interworking. This document is part of a package; see also [IIMCIMIBTRANS] [IIMCMIB-II] [IIMCPROXY] and [IIMCOMIBTRANS]. Distribution of this document is unlimited. Comments should be sent to the Network Management Forum IIMC working group (iimc@thumper.bellcore.com). This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au to learn the current status of any Internet Draft. LaBarre Expires November 29, 1993 Page i Draft ISO/CCITT and Internet Management Security 5/26/93 Abstract This document is intended to facilitate the multi-protocol management coexistence and interworking for networks that are managed using the ISO/CCITT Common Management Information Protocol (CMIP) and networks that are managed using the Internet Simple Network Management Protocol (SNMP). This document defines the end-to-end security architecture, services, and mechanisms for use with ISO/CCITT-Internet proxies. This document also contains the ISO/CCITT GDMO definition and registration of the SNMP Parties MIB, derived from the Internet SNMP Parties MIB [RFC1447] according to the procedures defined in "Translation of Internet MIBs to ISO/CCITT GDMO MIBs" [IIMCIMIBTRANS]. Table of Contents Status of this Memo......................................i Abstract.................................................ii Table of Contents........................................ii Revision History.........................................iv 1.1 Problem Statement...................................1 1.2 Overview of IIMC....................................1 1.3 MIB Translation Procedures..........................2 1.4 Native Management Model.............................3 1.5 Proxy Management Model..............................4 1.6 Scope of this Document..............................5 1.7 Terms and Conventions...............................5 2. Security and Management Considerations................5 2.1 General Considerations...............................6 2.1.1 Security of Management.............................6 2.1.2 Management of Security.............................6 2.1.3 Threat Characterization............................6 2.1.3.1 Communications Path Security.....................7 2.1.3.2 Managed System Security..........................8 2.2 ISO/CCITT to Internet Security Environment...........8 2.2.1 Security Model.....................................8 2.2.2 Supported Security Capabilities....................9 2.2.3 Internet Management Security.......................10 2.2.3.1 SNMPv1 Security..................................10 2.2.3.2 SNMPv2 Security..................................10 2.2.4 Constraints on Mapping Security Services...........11 2.2.5 ISO Access Control Framework and SNMP Security.....12 3. Security Specifications...............................13 3.1 ISO Manager to ISO/CCITT-Internet Proxy Security.....13 3.2 ISO/CCITT-Internet Proxy to Internet Agent Security..15 3.3 ISO/CCITT-Internet Proxy Access Control Enforcement..15 4. IIMC Party MIB........................................15 4.1 Party MIB GDMO Templates............................16 -- 4.1.1 Party MIB Managed Object Classes...............16 -- 4.1.2 Party MIB Attributes...........................22 -- 4.1.3 Party MIB Name Bindings........................39 -- 4.1.4 Party MIB Attribute Types......................42 LaBarre Expires November 29, 1993 Page ii Draft ISO/CCITT and Internet Management Security 5/26/93 4.2 Party MIB ASN.1 Modules .............................44 5. Acknowledgments .......................................45 References ...............................................47 Appendix A (Normative) Managed Object Conformance Statements (MOCS) ........50 LaBarre Expires November 29, 1993 Page iii Draft ISO/CCITT and Internet Management Security 5/26/93 Revision History Draft 0 - October 9, 1992 Initial draft of this document (previously entitled "IIMC: Translation of Internet Party MIB (RFC1353) to ISO/CCITT GDMO MIB" [IIMCPARTY]). Draft 1 - March 26, 1993 Previous draft of this document (replaced Draft 0). Draft 2 - May 26, 1993 Current draft of this document (replaces Draft 1). Major Changes Since Last Revision 1. Aligned templates with changes as per [IIMCIMIBTRANS]. - Added scannable BEHAVIOUR to all templates. - ASN.1 modules now use IMPORTS from RFCs. - Optimized ASN.1 module to reduce constructs. - Put GDMO templates and ASN.1 modules together to facilitate machine parsing of text. 2. Aligned Party MIB translation with [RFC1447]. - Registration corrected - Family views removed 3. Modified and expanded clause 2.2: - Modified 2.2.2 per Vancouver decisions. - Added 2.2.3 in Internet Management security - Modified 2.2.4 Constraints on Mapping Security Services to include an expanded definition of the problem and constraints on its solution. - Added 2.2.5 ISO Access Control Framework and SNMP Security. This presents the basis for specifying the proxy interface to the manager, using the characterization of the SNMP access control as a capability based scheme. 4. Modified and expanded clause 3 Security Specifications, to specify the security interface requirements more explicitly in accordance with decisions made in Vancouver, and in accordance with the capability characterization of SNMP access control. Outstanding Issues Review for approach correctness and completeness is requested. In addition, reviewers are asked to comment on the following question. 1. Should a security mechanism be specified for use in protecting passwords, e.g. MD5 or SHA? LaBarre Expires November 29, 1993 Page iv Draft ISO/CCITT and Internet Management Security 5/26/93 1. Introduction This section provides an overview of ISO/CCITT and Internet Management Coexistence (IIMC) activities, insight into the problem being addressed by IIMC, and a brief introduction to the strategy adopted by IIMC: use of translated MIBs in either a proxy or native implementation. The section concludes by describing the scope of this document, and terms and conventions used by this document. 1.1 Problem Statement The need for enterprise network management has been addressed by development of network management standards within various communities, most notably the ISO/CCITT and Internet communities. - The ISO/CCITT community developed the Common Management Information Protocol (CMIP) [ISO9596-1], and related SMI documents [ISO10165-1,2,4]. - The Internet community developed the Simple Network Management Protocol (SNMP) [RFC1157], and its successor, SNMPv2 [RFC1448]. The Internet SMI is defined in [RFC1155] and [RFC1442]. These standards share a nearly common management model, but diverge due to differing management philosophies. Although functionally similar, the Internet and ISO/CCITT protocols and SMIs differ in terms of their complexity and specific operations. Business requirements for end-to-end enterprise management include the need to integrate the management of components accessed by ISO/CCITT management, Internet management, and proprietary management mechanisms in a manner which presents a unified view of the network, despite protocol and SMI differences. For example, many telecommunications and computer vendors, represented by organizations such as the Network Management Forum (NMF), and the U.S. government, as specified in the Government Network Management Profile (GNMP), have based their enterprise management model on the ISO/CCITT management model. These organizations are particularly interested in integrated management of devices that use the Internet management. This interest is primarily due to the widespread commercial implementation and use of such devices, especially devices that use the Internet TCP/IP protocol suite. 1.2 Overview of IIMC This document is part of a package of ISO/CCITT and Internet Management Coexistence (IIMC) drafts. Documents included in this package are: LaBarre Expires November 29, 1993 Page 1 Draft ISO/CCITT and Internet Management Security 5/26/93 [IIMCIMIBTRANS] Translation of Internet MIBs to ISO/CCITT GDMO MIBs [IIMCOMIBTRANS] Translation of ISO/CCITT GDMO MIBs to Internet MIBs [IIMCMIB-II] Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO MIB [IIMCPROXY] ISO/CCITT to Internet Management Proxy [IIMCSEC] ISO/CCITT to Internet Management Security These documents together comprise a package aimed at integrating ISO/CCITT-based and Internet-based management systems. These documents represent coexistence and interworking efforts underway within the IIMC working group, chartered under the auspices of the Network Management Forum Architecture Integration ISO/Internet (AIII) technical team. The IIMC intends to address the problem that end-to-end management requires an integrated, unified view of the managed network, despite differences in management protocol and information structure. Integrated management can be facilitated by the development of "proxy" mechanisms which translate between functionally equivalent service, protocol, and SMI differences to create this unified view. MIB translation procedures can be used to support proxy management, as well as to take advantage of existing MIB definition and avoid duplication of effort. In this way, commercial investment in both ISO/CCITT and Internet- based management technologies can be preserved through deployment of common methods and tools which support integration. This overall strategy was outlined in a joint publication developed by the NM Forum and X/Open entitled "ISO/CCITT and Internet Management: Coexistence and Interworking Strategy" [NMFTR107]. The documents included in the IIMC package are the next level of detailed specifications which implement several of the methodologies identified in the strategy. 1.3 MIB Translation Procedures The foundation of IIMC is provided by a pair of Management Information Base (MIB) translation procedures. - [IIMCIMIBTRANS] specifies translation procedures for converting MIBs from Internet MIB macro format into ISO/CCITT GDMO template format. - [IIMCOMIBTRANS] specifies translation procedures for converting MIBs from ISO/CCITT GDMO template format into Internet MIB macro format. LaBarre Expires November 29, 1993 Page 2 Draft ISO/CCITT and Internet Management Security 5/26/93 The IIMC approach is to specify direct translation procedures which yield a pair of functionally-equivalent MIBs, as shown in the following figure. +----------------+ +--------------------+ +----------------+ | Internet MIB | | MIB Translation | | GDMO MIB | | | | Procedures | | | | Format = | | Specified By | | Format = | | [RFC1212] & |---->| [IIMCIMIBTRANS] or |---->| [ISO10165-1] & | | [RFC1442] |<----| [IIMCOMIBTRANS] |<----| [ISO10165-4] | +----------------+ +--------------------+ +----------------+ MIBs translated by these procedures may be used to take advantage of existing MIB definitions when business needs require deployment in a different management environment. Translated MIBs may also be used to provide uniformity when multiple management environments are supported by a single system (e.g., dual stack managers). Finally, IIMC MIB translation procedures may be used to support service emulation by a proxy. 1.4 Native Management Model The basic model for ISO/CCITT and Internet management is illustrated in the following diagram. Manager Agent +-----------------------+ +----------------------+ |+---------------------+| |+-------------------+ | || Management || || Managed | | || Applications || || Resources | | |+---------------------+| |+-------------------+ | | | | | | | | | | | | | |+-----------+---------+| |+----------+---------+| || Manager | MIB || || Agent | MIB || |+-----------+---------+| |+----------+---------+| | | | | | | | | Management | | | Management | | | Services | | | Services | +-----------------------+ +----------------------+ | Management Protocol | | Management Protocol | +-----------------------+ +----------------------+ ^ ^ | | +------------------------------------+ Protocol Messages Within IIMC documents, this model is referred to as the "native" management model. MIBs translated using IIMC procedures can be used by "native" agent implementations. For example, an ISO/CCITT agent can make visible TCP/IP managed resources using the translated GDMO version of the Internet MIB-II [RFC1213] specified by [IIMCMIB-II]. Dual-stack managers or agents may LaBarre Expires November 29, 1993 Page 3 Draft ISO/CCITT and Internet Management Security 5/26/93 also be implemented which support both the original MIB and the translated MIB generated using IIMC-specified procedures. 1.5 Proxy Management Model The basic model for ISO/CCITT to Internet proxy management is illustrated in the following diagram. This proxy is specified by [IIMCPROXY]. A similar approach could also be taken to specify an Internet to ISO/CCITT proxy, although no such IIMC document is currently specified. Manager Proxy Agent +-----------------------+ +---------------------+ +----------------------+ |+---------------------+| |+------+ +----------+| |+-------------------+ | || Management || || GDMO | | Internet || || Managed | | || Applications || || MIB | | MIB || || Resources | | |+---------------------+| |+------+ +----------+| |+-------------------+ | | | | |+-------------------+| | | | | | | || Service || | | | | | | || Emulation || | | | | | | ||(scoping) || | | | | | | || (filtering) || | | | | | || (operations)|| | | | |+-----------+---------+| |+-------------------+| |+----------+---------+| || ISO/CCITT | GDMO || || Protocols Mapping || || Internet | Internet|| || Manager | MIB || || CMIS |...| SNMP || || Agent | MIB || |+-----------+---------+| |+-------------------+| |+----------+---------+| | | | | |CMIS | | | | | | | CMIS Services | | |Services | | | | SNMP "Services" | | | | | | | | | | | | | | | | SNMP| | | | | | | | | | "Services"| | | | | +-----------------------+ +---------------------+ +----------------------+ | CMIP | | CMIP | SNMP | | SNMP | +-----------------------+ +---------------------+ +----------------------+ ^ ^ ^ ^ | | | | +---------------------+ +-------------------+ CMIP Messages SNMP Messages This ISO/CCITT to Internet proxy provides emulation of CMIS services by mapping to the corresponding SNMP message(s) necessary to carry out the service request. The service emulation allows management of Internet objects by an ISO/CCITT manager. The left hand side of the proxy behaves like an ISO/CCITT agent, communicating with the ISO/CCITT manager using CMIP protocols. The right hand side of the proxy behaves like an Internet manager, communicating with the Internet agent using SNMP protocols. The proxy relies on the existence of a pair of directly-related MIB definitions, where the Internet MIB has been translated into ISO/CCITT GDMO using the procedures specified in [IIMCIMIBTRANS]. The proxy uses these MIB definitions and rules LaBarre Expires November 29, 1993 Page 4 Draft ISO/CCITT and Internet Management Security 5/26/93 to provide run-time translation of management information carried in service requests and responses. The proxy is designed with a specified interface between the proxy and the underlying protocol stacks, and so deals primarily in terms of CMIS services and SNMP "services". The proxy emulates services such as CMIS scoping and filtering, processing of CMIS operations, and forwarding/logging of CMIS notifications by performing a mapping process which must be tailored for each protocol (for example, SNMPv1 and SNMPv2 are variants of the same protocol mapping process). 1.6 Scope of this Document One of the IIMC objectives is to provide for the secure end-to- end management of resources managed using ISO/CCITT and Internet management services, protocols and SMI. Security and management by their very nature are entwined such that each needs the services of the other. Security services are required to protect management services. Management services are required to monitor and control security services. This document (IIMCSEC) defines the security architecture for end-to-end security between an ISO/CCITT manager and an Internet agent via proxies such as that defined in [IIMCPROXY]. The architecture requires that information required to support Internet security mechanisms from an end-to-end perspective, and to manage it, be translated into the ISO/CCITT SMI. This document applies the procedures described in [IIMCIMIBTRANS] to the translation and registration of the Internet SNMP Parties MIB defined in [RFC1447]. 1.7 Terms and Conventions This document assumes that the reader is familiar with ISO/CCITT management and Internet management, and the terminology of each. The term "SNMP" is used throughout this document to indicate either SNMPv1 or SNMPv2, unless a distinction needs to be made. This document assumes that the reader is familiar with the ISO/CCITT and Internet management security services, protocols and mechanisms. This document assumes that the reader is familiar with the Internet to SMI translation procedures defined in [IIMCIMIBTRANS]. Other terms and conventions used throughout this document are defined in Section 2. 2. Security and Management Considerations Security and management are entwined by their very nature such that each needs the services of the other. Security services are LaBarre Expires November 29, 1993 Page 5 Draft ISO/CCITT and Internet Management Security 5/26/93 needed to protect management services. Management services are needed to monitor and control security services. These considerations are briefly presented in this section. 2.1 General Considerations 2.1.1 Security of Management Management is most vulnerable to security attacks at the manager user interface, the communications path over which management messages are transmitted, and at the managed system that contains the resources being managed. Accordingly, management's security considerations are to overcome these threats by: - Preventing unauthorized operator access to manager applications and associated management information contained in a manager workstation, - Protecting management information in transit between managers and agents, and - Enforcing management policy regarding access to information within the managed system. Preventing unauthorized access to manager applications is beyond the scope of this document, and therefore will not be discussed. The characterization of the security threats in relation to the other two vulnerable areas are discussed more fully in the following sections. 2.1.2 Management of Security Security requires management support for three basic activities: - monitoring and control of security mechanisms, - detection of security related events through security alarm generation, reporting and audit trail analysis, and - damage assessment and recovery from a security attack. Security mechanisms and algorithm resources are modeled as managed objects and the management information is stored in a secure portion of the management information base. The same management and security mechanisms used to manage non-security managed objects may be applied to the management of security objects. 2.1.3 Threat Characterization Security threats for management are the same as for any distributed application. Security threats can be characterized as being active or passive. Active threats to a management LaBarre Expires November 29, 1993 Page 6 Draft ISO/CCITT and Internet Management Security 5/26/93 system may effect changes to the state or operation of the managed resource. Examples of active threats are malicious changes to the routing tables of a system, or to the objects used to control decisions related to policies, such as security policies relating to resource access. Active threats include: - masquerade, - modification and fabrication of messages and stored data, - replay and reordering of messages, and - denial of management services. Passive threats are those which, if realized, would not result in any modifications to information contained in the system, e.g., management information, and where neither the operation nor the state of the system is changed. Passive threats include: - disclosure of message contents and stored data, - traffic analysis, and - repudiation. 2.1.3.1 Communications Path Security The threats to the communications path used for manager to agent communications, and applicable security services include: - modification and fabrication of management messages * integrity - disclosure of management message data * confidentiality, selective field confidentiality - replay and reordering of messages * integrity - denial of management services * continuity of operations - traffic analysis * confidentiality Note that the communications path from the manager to an agent may be direct, or indirect via the management applications of an intermediate manager or proxy. In the indirect case, the portion of the message that must be exposed in the intermediate manager for the purpose of application layer relaying is subject to unauthorized disclosure and modification. Such entities must be trusted not to perform such modifications or to disclose the contents of the management messages. Selective field confidentially services may be needed if intermediate managers LaBarre Expires November 29, 1993 Page 7 Draft ISO/CCITT and Internet Management Security 5/26/93 or proxies are acting as application layer relays in the path. Such selective field services allow only the information in management messages needed for application layer routing to be unprotected while preventing other fields in the message from disclosure or modification. 2.1.3.2 Managed System Security The threats to the managed system include: - masquerade of a manager application or operator * peer authentication, data origin authentication - modification and fabrication of data residing in the management information base * access control, data integrity - disclosure of management data in the managed system * access control, confidentiality - repudiation of management requests at destination * non-repudiation at destination. Non-repudiation services may be provided in circumstances where such accountability is needed. While the non-repudiation service does nothing to protect the network, it does provide the capability to trace the entities that are to be blamed for mis- management. 2.2 ISO/CCITT to Internet Security Environment 2.2.1 Security Model The model for IIMC end-to-end security is illustrated in the following figure. The objective is to provide continuity of security services from the ISO/CCITT Manager through to the Internet Agent. The end-to-end solution is constrained by the security services available at the Internet agent and those available at the ISO/CCITT Manager. The mapping of security services is provided by the ISO/CCITT-Internet proxy. The mapping of those services at the proxy will depend upon the availability of the services and the compatibility of the mechanisms used to provide the services. This figure illustrates the proxy in a separate device from the manager or the agent. If the proxy function is performed in the manager, then how the manager's internal security mechanisms map to Internet security services is beyond the scope of this document. If ISO management services and protocol are provided in the managed device (native CMIP agent), then ISO security services apply at the managed system. The mapping of any ISO security services that may still possibly apply at the internal proxy to Internet agent interface into equivalent Internet services, e.g., authentication and access control, is beyond the LaBarre Expires November 29, 1993 Page 8 Draft ISO/CCITT and Internet Management Security 5/26/93 scope of this document. ISO/CCITT Manager ISO/CCITT-Internet Proxy Internet Agent +-----------------------+ +----------------------+ +-------------+ | | |+--------------------+| | | | | || security service || | | | | || mapping || | | | | |+--------------------+| | | |+---------------------+| |+-------+ +----------+| |+-----------+| || ISO/CCITT || || ISO | | Internet || || Internet || || Manager || || agent | | manager || || agent || || role || || role | | role || || role || |+---------------------+| |+-------+ +----------+| |+-----------+| | CMIP | | CMIP | | SNMP || | SNMP | +-----------------------+ +---------------------+ +-------------+ ^ ^ ^ ^ | | | | +---------------------+ +-------------------+ CMIP Messages SNMP Messages - ISO peer authentication - ISO data origin authentication* - Internet data origin authentication# - ISO integrity, confidentiality* - Internet integrity, confidentiality# - Internet access control - Internet access control# - ISO access control+ * OSI application layer standards are in progress. These services maybe provided by lower layers in some environments, e.g., transport and network # SNMPv1 and SNMPv2 have different mechanisms (or none) + ISO access control may be applied by the proxy to GDMO objects, if enforcement is at the proxy. IIMC End-to-end Security Model The security services do not have to be provided at the same layers in the protocol suites on the two external proxy interfaces. For example, integrity and confidentiality services may be applied at the transport or network layer at the interface to the ISO/CCITT manager, and at the application layer at the interface to the Internet agent. Depending on the environment, some security services may not be needed at a proxy's interface to the ISO/CCITT manager. For example, data origin authentication and confidentiality services may not be needed if the two devices are close together and physical security is adequate to satisfy the security policy. 2.2.2 Supported Security Capabilities The basic security capabilities to be met by the architecture for providing end-to-end security services are support for: LaBarre Expires November 29, 1993 Page 9 Draft ISO/CCITT and Internet Management Security 5/26/93 - enforcement of SNMPv1 security services at the agent (community string), - enforcement of SNMPv2 security services at the agent (party/context based), - enforcement of access control at the proxy using OSI access control mechanisms (ISO 10164-9) for the ISO/CCITT managed objects derived from Internet objects for all proxied agents, and for the MIB specific to the proxy [IIMCPROXY], - OSI security services between the ISO/CCITT manager and the proxy, and - mapping of OSI security services into Internet security services, where possible, and forwarding from the ISO/CCITT manager of information needed for Internet security mechanisms. 2.2.3 Internet Management Security The security services for Internet management differs depending on the version of SNMP (SNMPv1 or SNMPv2) used. 2.2.3.1 SNMPv1 Security The SNMPv1 security relies on the transfer of an unprotected community string that represents the capabilities that the initiator has with respect to operations on a set of objects. 2.2.3.2 SNMPv2 Security The SNMPv2 security architecture relies on the identification of distinct, globally unique, entities, called "parties", for peers that exchange SNMP messages [RFC1445]. Multiple parties may exist at the manager and at the agent. Each distinct SNMPv2 peer is identified by a "party identifier", an OID. Associated with the party identifier are it's agent address, and parameters for access control, authentication, integrity and confidentiality services which may be used when communicating with other parties. Since parties form a peer relationship, these security service parameters for peer parties must be compatible. The peer relationship between SNMPv2 parties is established via an associated "context", identified by an OID, which provides a means to identify constraints on valid management operations and access to associated resources (MIB objects). The context also specifies whether the constraints apply to local resources or to remote resources via a (yet another) proxy relationship. LaBarre Expires November 29, 1993 Page 10 Draft ISO/CCITT and Internet Management Security 5/26/93 The minimal SNMPv2 security service allowed is access control as specified by the source (srcParty), destination party (dstParty), and context identifiers. SNMPv2 requests that do not contain all three identifiers are discarded. As discussed in 2.2.5, the access control scheme used by SNMP security can be considered a form of capability scheme. 2.2.4 Constraints on Mapping Security Services The mapping of security services end-to-end is primarily constrained by the security services available at the Internet agent. The possible application level security services at Internet agents is well defined for SNMPv1, and for SNMPv2 (currently proposed draft standard). However, it cannot be assumed that all Internet agents will implement the full range of their defined security services, or that they are all required for any given environment. Given the known potential availability of Internet security services at Internet agents, and at the Internet proxy, three major problems arise in proxy situations: a) Selection from the security services available at the Internet proxy to Internet agent interface of those services that are appropriate to the threats at that interface, according to the established security policy. b) Providing security services at the ISO manager to Internet proxy interface that are appropriate to the threats at that interface, according to the established security policy. c) Transfer to the Internet proxy from the ISO manager of security parameters required for Internet proxy to Internet agent security. Note: An exact mapping of security services between both Internet proxy interfaces may not be required. The environments at the two interfaces may be completely different, e.g., the manager and proxy may be in the same room while the agents are geographically distributed. Assume the following environment and constraints. i) The ISO/CCITT-Internet proxy is geographically remote from both the ISO/CCITT manager and the Internet agents, and the threats at both interfaces are the same. ii) Only application level security services are used. iii) The Internet agents and Internet proxy support the full range of security services defined for them. They include, for the respective SNMP versions: LaBarre Expires November 29, 1993 Page 11 Draft ISO/CCITT and Internet Management Security 5/26/93 Service SNMPv1 SNMPv2 Peer Authentication - X Data Origin Authentication - X Access Control x X Connectionless Integrity - X Connectionless Confidentiality - X Replay, Reorder Protection - X The first problem (a) can be solved by configuring the security parameters of the Internet agents and Internet proxy, either through local or remote management mechanisms. The second problem (b) can be solved by implementing the appropriate OSI management services in the ISO/CCITT manager and ISO/CCITT-Internet proxy, and configuring the mechanisms to provide the service. This problem is complicated by the current lack of Stable OSI security standards for data origin authentication, integrity, confidentiality, and access control. The third problem (c) can be solved by using an access control certificate to transfer the Internet security parameters. This problem is complicated by the current lack of a stable standard for access control certificates. Given the necessity for such transfers in proxy situations, an preliminary ACC will have to be used. However, an attempt should be made to align as closely as possible with proposed ISO standards. 2.2.5 ISO Access Control Framework and SNMP Security The SNMP access control schemes can be most nearly categorized as capability schemes using the definitions in the ISO Access Control Framework [ISO10181-3]. A capability defines a set of allowed operations that the initiator of the operation is allowed to perform on an identified set of targets. The SNMPv1 scheme is a very weak capability scheme which uses the community string to identify which operations are permitted or not permitted on a set of objects. However the community string is not bound to the initiator, i.e., it may possibly be changed in transit. Proof of its authenticity can be inferred from the fact that the SNMPv1 agent is configured to have knowledge of the capabilities represented by the community string. In that sense, the person that configured the community string, either via local mechanisms, or via remote management mechanisms can be considered to provide the third party proof of authenticity. The SNMPv2 scheme is a stronger capability scheme which uses the combination of SNMPv2 srcParty, dstParty, and context identifiers to identify which operations are permitted or not- permitted on a set of objects. The srcParty binds it to the initiator of the request. Proof of its authenticity can be LaBarre Expires November 29, 1993 Page 12 Draft ISO/CCITT and Internet Management Security 5/26/93 inferred from the fact that the SNMPv2 agent is configured to have knowledge of the capabilities represented by the interrelated parameters. In that sense, the person that configured the Internet Party MIB, either via local mechanisms, or via remote management mechanisms can be considered to provide the third party proof of authenticity. Capabilities may be carried in access control tokens or access control certificates (ACC). Tokens and certificates are similar. A token differs from a certificate in that it is not created by an entity which is a security authority, and it does not necessarily contain an indication of the time period for which it is valid. The sealing of the ACC by a security authority and the provision of a time period for which it is valid provides third party proof of its authenticity. 3. Security Specifications 3.1 ISO Manager to ISO/CCITT-Internet Proxy Security OSI peer authentication services shall be supported in accordance with OMNIPoint 1 security specifications in [NMF016] Annex B. At minimum, the simple authentication, protected password, shall be supported as specified in [NMF016] Annex B.2. Editor's Note: [Should a protection algorithm be specified, e.g. MD5 or SHA?] OSI data origin authentication services, integrity services, confidentiality services, and access control services are currently beyond the scope of this document due to the lack of stable relevant ISO security standards. Specifications for these services will be defined in a future Issue when the relevant base standards become International Standards. Support shall be provided for the transfer of Internet security service parameters from the ISO/CCITT manager to an ISO/CCITT- Internet proxy at the time of management association establishment, and with CMIP requests. Access control security parameters shall be transferred as security attributes of an Access Control Certificate (ACC), also referred to as a Privilege Attribute Certificate (PAC). Implementations shall support the ACC defined in OMNIPoint 1 [NMF016] Annex K, and the associated PICS in Annex E.8.8. To allow for later inclusion of security attributes for OSI access control, the ACC transferred to an ISO/CCITT-Internet proxy shall be a compound ACC, with the first ACC in the sequence of contained ACCs being the ACC with the SNMP security attributes. The containing ACC of the compound ACC transferred to an ISO/CCITT-Internet proxy shall contain the privilegeAttributes sequence, in accordance with [NMF016] Annex E.8.8. The privilegeAttributes sequence may be empty. LaBarre Expires November 29, 1993 Page 13 Draft ISO/CCITT and Internet Management Security 5/26/93 The Internet security parameters shall be transferred using the security attributes defined by [ECMA138]. The security attributes are defined in the Security-Services-Attributes module in [ECMA138] using the attribute macro defined for the ISO Directory Services [ISO9594]. For ease of use, these definitions are repeated below; in the event of transcription error, the original source specifications are normative. The security parameters to be transferred in the ACC shall include the Security-capability-type-1 attribute as defined in [ECMA138]. The Security-capability-type-1 attribute grants access of the type accessType to the object(s) defined by objectDefiner. Security-capability-type-1 ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX CapabilityType1 SINGLE VALUE CapabilityType1 ::= SEQUENCE { objectDefiner ObjectDefiner, accessType AccessDefiner} ObjectDefiner ::= IntegerOrString AccessDefiner ::= IntegerOrString IntegerOrString ::= CHOICE { integerPart INTEGER, stringPart IA5String} The IntegerOrString choice shall be Ia5String. The Security-capability-type-1 attribute is registered as: desd-att-capability-type-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) icd-ecma(0012) standard(0) desd(138) attributeIdentifiers(3) 4} The Security-capability-type-1 attribute shall be used for proxy to SNMPv1 agents to carry the community string indicating the accessType. The objectDefiner shall be undefined and represented as an empty string (''H). The Security-capability-type-1 attribute shall be used for proxy to SNMPv2 agents to carry the srcParty and dstParty as the objectDefiners, and the context identifier as the accessType. The contents of the Security-capability-type-1 attribute shall be as described below. ----------------------+----------------+--------------- LaBarre Expires November 29, 1993 Page 14 Draft ISO/CCITT and Internet Management Security 5/26/93 [ECMA138] | SNMPv2 | SNMPv1 Security | Security | Security Attribute | Parameter | Parameter ----------------------+----------------+----------------- Security-capability | | -type-1 | | objectDefiner | src/dst Parties| ""H accessType | context | community string ----------------------+----------------+----------------- The src/dst Parties are the srcParty and dstParty SNMPv2 parameters separated by a slash (/). The SNMPv2 parameters shall be ASN.1 object identifiers represented using the "dot" notation convention, where the OID sub-identifiers are represented in decimal character form and separated by decimal points. For example, {1 3 6 1 6 3 3 2 3 1 1 3} is represented as "1.3.6.1.6.3.3.2.3.1.1.3". 3.2 ISO/CCITT-Internet Proxy to Internet Agent Security An ISO/CCITT-Internet proxy that supports SNMPv1 shall support the community string security services as defined in [RFC1157]. An ISO/CCITT-Internet proxy that supports SNMPv2 shall support the security services as defined in [RFC1447], with minimal support for the "Party No Privacy" compliance level specified by clause 3.7.1 of [RFC1447]. 3.3 ISO/CCITT-Internet Proxy Access Control Enforcement Access control enforcement at the ISO/CCITT-Internet proxy is currently beyond the scope of this document. However, access control enforcement at the proxy will be based on OSI access control for management as defined in [ISO10164-9] when it becomes an International Standard. 4. IIMC Party MIB Support for the SNMPv2 security services requires that the Internet Party MIB [RFC1447] be instantiated in the ISO/CCITT- Internet proxy and SNMPv2 agents. The IIMC Party MIB is derived from the Internet Party MIB defined in [RFC1447]. Adjustments have been made to the behavior of some elements in the MIB to accommodate SNMPv1 community string based security. A Naming Tree diagram for IIMC Party MIB managed object classes is illustrated below. The IIMC Party MIB is subordinate to the ISO/CCITT system managed object that represents the Internet agent or proxy. "Rec. X.721 | ISO/IEC 10165-2 : 1992" : system LaBarre Expires November 29, 1993 Page 15 Draft ISO/CCITT and Internet Management Security 5/26/93 | | |-- partyTable --- partyEntry | |-- contextTable --- contextEntry | |-- aclTable --- aclEntry | |-- viewTable --- viewEntry The IIMC Party MIB elements that are specific to the proxy, i.e., local, should be instantiated under the ISO system object that is specific to the proxy. The IIMC MIB elements that are specific to each SNMP agent are actually instantiated in the SNMP agent. Duplicates of MIB elements instantiated in the SNMP agent should not be instantiated in the proxy if a stateless approach to proxy is used as described in [IIMCPROXY]. The GDMO templates and ASN.1 modules are included here in one section to facilitate automated processing. Comments and subsection headers are included in the form of ASN.1 comments, i.e., preceded by "--". This document (IIMCSEC) is allocated the following registration identifier for purposes of referencing material contained herein. iimcIIMCSEC OBJECT IDENTIFIER ::={iimcManagementDocMan 4} 4.1 Party MIB GDMO Templates -- 4.1.1 Party MIB Managed Object Classes aclEntry MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY aclEntryPkg PACKAGE BEHAVIOUR aclEntryPkgBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This managed object class maps to aclEntry object in [RFC1447].!!; DESCRIPTION !!The access privileges for a particular requesting SNMP party in accessing a particular target SNMP party.!!; INDEX aclSubject, aclTarget, aclResources; ENDPARSE!;; ATTRIBUTES {iimcManagementDocMan 1}:internetClassId GET, aclTarget GET, aclSubject GET, LaBarre Expires November 29, 1993 Page 16 Draft ISO/CCITT and Internet Management Security 5/26/93 aclResources GET, aclPrivileges DEFAULT VALUE IIMCPartyMIB.c-aclPrivileges GET-REPLACE, aclStorageType DEFAULT VALUE IIMCPartyMIB.c-DEFAULTStorageType GET-REPLACE, aclStatus GET;;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 3 1 1}; aclTable MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY aclTablePkg PACKAGE BEHAVIOUR aclTableBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This managed object class maps to aclTable object in [RFC1447].!!; DESCRIPTION !!The access privileges database.!!; CONCEPTUALTABLE ENDPARSE!;; ATTRIBUTES {iimcManagementDocMan 1}:internetClassId GET;;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 3 1}; contextEntry MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY contextEntryPkg PACKAGE BEHAVIOUR contextEntryPkgBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This managed object class maps to contextEntry object in [RFC1447].!!; DESCRIPTION !!Locally held information about a particular SNMPv2 context.!!; INDEX contextIdentity; ENDPARSE!;; ATTRIBUTES {iimcManagementDocMan 1}:internetClassId GET, contextIdentity GET, contextIndex GET-REPLACE, contextLocal DEFAULT VALUE IIMCPartyMIB.c-contextLocal GET-REPLACE, contextViewIndex GET-REPLACE, contextLocalEntity DEFAULT VALUE LaBarre Expires November 29, 1993 Page 17 Draft ISO/CCITT and Internet Management Security 5/26/93 IIMCPartyMIB.c-DEFAULTNullString GET-REPLACE, contextLocalTime DEFAULT VALUE IIMCPartyMIB.c-contextLocalTime GET-REPLACE, contextProxyDstParty GET-REPLACE, contextProxySrcParty GET-REPLACE, contextProxyContext GET-REPLACE, contextStorageType DEFAULT VALUE IIMCPartyMIB.c-DEFAULTStorageType GET-REPLACE, contextStatus GET;;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1}; contextTable MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY contextTablePkg PACKAGE BEHAVIOUR contextTablePkgBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This managed object class maps to contextTable object in [RFC1447].!!; DESCRIPTION !!The SNMPv2 Context database.!!; CONCEPTUALTABLE ENDPARSE!;; ATTRIBUTES {iimcManagementDocMan 1}:internetClassId GET;;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1}; partyEntry MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992":top; CHARACTERIZED BY partyEntryPkg PACKAGE BEHAVIOUR partyEntryPkgBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This managed object class maps to partyEntry object in [RFC1447].!!; DESCRIPTION !!Locally held information about a particular SNMPv2 party.!!; INDEX partyIdentity; ENDPARSE!;; ATTRIBUTES {iimcManagementDocMan 1}:internetClassId GET, partyIdentity GET, partyIndex GET, partyTDomain DEFAULT VALUE LaBarre Expires November 29, 1993 Page 18 Draft ISO/CCITT and Internet Management Security 5/26/93 IIMCPartyMIB.c-partyTDomain GET-REPLACE, partyTAddress DEFAULT VALUE IIMCPartyMIB.c-partyTAddress GET-REPLACE, partyMaxMessageSize DEFAULT VALUE IIMCPartyMIB.c-partyMaxMessageSize GET-REPLACE, partyLocal DEFAULT VALUE IIMCPartyMIB.c-partyLocal GET-REPLACE, partyAuthProtocol DEFAULT VALUE IIMCPartyMIB.c-partyAuthProtocol GET-REPLACE, partyAuthClock DEFAULT VALUE IIMCPartyMIB.c-partyAuthClock GET-REPLACE, partyAuthPrivate DEFAULT VALUE IIMCPartyMIB.c-DEFAULTNullString GET-REPLACE, partyAuthPublic DEFAULT VALUE IIMCPartyMIB.c-DEFAULTNullString GET-REPLACE, partyAuthLifetime DEFAULT VALUE IIMCPartyMIB.c-partyAuthLifetime GET-REPLACE, partyPrivProtocol DEFAULT VALUE IIMCPartyMIB.c-partyPrivProtocol GET-REPLACE, partyPrivPrivate DEFAULT VALUE IIMCPartyMIB.c-DEFAULTNullString GET-REPLACE, partyPrivPublic DEFAULT VALUE IIMCPartyMIB.c-DEFAULTNullString GET-REPLACE, partyCloneFrom GET-REPLACE, partyStorageType DEFAULT VALUE IIMCPartyMIB.c-DEFAULTStorageType GET-REPLACE, partyStatus GET;;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1}; LaBarre Expires November 29, 1993 Page 19 Draft ISO/CCITT and Internet Management Security 5/26/93 partyTable MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY partyTablePkg PACKAGE BEHAVIOUR partyTablePkgBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This managed object class maps to partyTable object in [RFC1447].!!; DESCRIPTION !!The SNMPv2 Party database.!!; CONCEPTUALTABLE ENDPARSE!;; ATTRIBUTES {iimcManagementDocMan 1}:internetClassId GET;;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 }; viewEntry MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY viewEntryPkg PACKAGE BEHAVIOUR viewEntryPkgBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This managed object class maps to viewEntry object in [RFC1447].!!; DESCRIPTION !!Information on a particular family of view subtrees included in or excluded from a particular SNMPv2 context's MIB view. Implementations must not restrict the number of families of view subtrees for a given MIB view, except as dictated by resource constraints on the overall number of entries in the viewTable.!!; INDEX viewIndex, viewSubtree; ENDPARSE!;; ATTRIBUTES {iimcManagementDocMan 1}:internetClassId GET, viewIndex GET, viewSubtree GET, viewMask DEFAULT VALUE IIMCPartyMIB.c-DEFAULTNullString GET-REPLACE, viewType DEFAULT VALUE IIMCPartyMIB.c-viewType GET-REPLACE, viewStorageType DEFAULT VALUE IIMCPartyMIB.c-DEFAULTStorageType GET-REPLACE, LaBarre Expires November 29, 1993 Page 20 Draft ISO/CCITT and Internet Management Security 5/26/93 viewStatus GET;;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 4 1 1}; viewTable MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY viewTablePkg PACKAGE BEHAVIOUR viewTableBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This managed object class maps to partyTable object in [RFC1447].!!; DESCRIPTION !!Locally held information about the MIB views known to this SNMPv2 entity. Each SNMPv2 context which is locally accessible has a single MIB view which is defined by two collections of view subtrees: the included view subtrees, and the excluded view subtrees. Every such subtree, both included and excluded, is defined in this table. To determine if a particular object instance is in a particular MIB view, compare the object instance's OBJECT IDENTIFIER with each of the MIB view's entries in this table. If none match, then the object instance is not in the MIB view. If one or more match, then the object instance is included in, or excluded from, the MIB view according to the value of viewType in the entry whose value of viewSubtree has the most sub-identifiers. If multiple entries match and have the same number of sub-identifiers, then the lexicographically greatest instance of viewType determines the inclusion or exclusion. An object instance's OBJECT IDENTIFIER X matches an entry in this table when the number of sub- identifiers in X is at least as many as in the value of viewSubtree for the entry, and each sub- identifier in the value of viewSubtree matches its corresponding sub-identifier in X. Two sub identifiers match either if the corresponding bit of viewMask is zero (the 'wild card' value), or if they are equal. Due to this 'wild card' capability, we introduce the term, a 'family' of view subtrees, to refer to the set of subtrees defined by a particular combination of values of viewSubtree and viewMask. In the case where no 'wild card' is defined in viewMask, the family of view subtrees reduces to a single view subtree.!!; CONCEPTUALTABLE ENDPARSE!;; ATTRIBUTES {iimcManagementDocMan 1}:internetClassId GET;;; LaBarre Expires November 29, 1993 Page 21 Draft ISO/CCITT and Internet Management Security 5/26/93 REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 4 1 }; -- 4.1.2 Party MIB Attributes aclPrivileges ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.AclPrivileges; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR aclPrivilegesBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The access privileges which govern what management operations a particular target party may perform with respect to a particular SNMPv2 context when requested by a particular subject party. These privileges are specified as a sum of values, where each value specifies a SNMPv2 PDU type by which the subject party may request a permitted operation. The value for a particular PDU type is computed as 2 raised to the value of the ASN.1 context-specific tag for the appropriate SNMPv2 PDU type. The values (for the tags defined in [RFC1448]) are defined in [RFC1445] as: Get : 1 GetNext : 2 Response : 4 Set : 8 unused : 16 GetBulk : 32 Inform : 64 SNMPv2-Trap : 128 The null set is represented by the value zero.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 3 1 1 4}; aclResources ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.Index; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR aclResourcesBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The value of an instance of this object identifies a SNMPv2 context in an access control LaBarre Expires November 29, 1993 Page 22 Draft ISO/CCITT and Internet Management Security 5/26/93 policy, and has the same value as the instance of the contextIndex object for that SNMPv2 context.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 3 1 1 3}; aclStatus ATTRIBUTE DERIVED FROM {iimcManagementDocMan 1}:rowStatus; BEHAVIOUR aclStatusBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The status of this conceptual row in the aclTable.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 3 1 1 6}; aclStorageType ATTRIBUTE DERIVED FROM storageType; BEHAVIOUR aclStorageTypeBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The storage type for this conceptual row in the aclTable.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 3 1 1 5}; aclSubject ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.Index; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR aclSubjectBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The value of an instance of this object identifies a SNMPv2 party which is the subject of an access control policy, and has the same value as the instance of the partyIndex object for that SNMPv2 party.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 3 1 1 2}; aclTarget ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.Index; MATCHES FOR EQUALITY, ORDERING; LaBarre Expires November 29, 1993 Page 23 Draft ISO/CCITT and Internet Management Security 5/26/93 BEHAVIOUR aclTargetBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The value of an instance of this object identifies a SNMPv2 party which is the target of an access control policy, and has the same value as the instance of the partyIndex object for that party.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 3 1 1 1}; contextIdentity ATTRIBUTE DERIVED FROM context; BEHAVIOUR contextIdentityBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!A context identifier uniquely identifying a particular SNMPv2 context.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 1}; contextIndex ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.Index; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR contextIndexBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!A unique value for each SNMPv2 context. The value for each SNMPv2 context must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 2}; contextLocal ATTRIBUTE DERIVED FROM {iimcManagementDocMan 1}:truthValue; BEHAVIOUR contextLocalBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type LaBarre Expires November 29, 1993 Page 24 Draft ISO/CCITT and Internet Management Security 5/26/93 defined in [RFC1447] by the same name.!!; DESCRIPTION !!An indication of whether this context is realized by this SNMPv2 entity.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 3}; contextViewIndex ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.Index; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR contextViewIndexBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!If the value of an instance of this object is zero, then this corresponding conceptual row in the contextTable refers to a SNMPv2 context which identifies a proxy relationship; the values of the corresponding instances of the contextProxyDstParty, contextProxySrcParty, and contextProxyContext objects provide further information on the proxy relationship. Otherwise, if the value of an instance of this object is greater than zero, then this corresponding conceptual row in the contextTable refers to a SNMPv2 context which identifies a MIB view of a locally accessible entity; the value of the instance identifies the particular MIB view which has the same value of viewIndex; and the value of the corresponding instances of the contextLocalEntity and contextLocalTime objects provide further information on the local entity and its temporal domain.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 4}; contextLocalEntity ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.OctetString; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR contextLocalEntityBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object identifies the local entity whose management information is in LaBarre Expires November 29, 1993 Page 25 Draft ISO/CCITT and Internet Management Security 5/26/93 the SNMPv2 context's MIB view. The empty string indicates that the MIB view contains the SNMPv2 entity's own local management information; otherwise, a non-empty string indicates that the MIB view contains management information of some other local entity, e.g.,'Repeater1'.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 5}; contextLocalTime ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ObjectIdentifier; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR contextLocalTimeBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object identifies the temporal context of the management information in the MIB view.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 6}; contextProxyDstParty ATTRIBUTE DERIVED FROM party; BEHAVIOUR contextProxyDstPartyBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!If the value of the corresponding instance of the contextViewIndex is equal to zero, then the value of an instance of this object identifies a SNMPv2 party which is the proxy destination of a proxy relationship. If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object is zero.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 7}; contextProxySrcParty ATTRIBUTE DERIVED FROM party; BEHAVIOUR contextProxySrcPartyBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE LaBarre Expires November 29, 1993 Page 26 Draft ISO/CCITT and Internet Management Security 5/26/93 REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!If the value of the corresponding instance of the contextViewIndex is equal to zero, then the value of an instance of this object identifies a SNMPv2 party which is the proxy source of a proxy relationship. Interpretation of an instance of this object depends upon the value of the transport domain associated with the SNMPv2 party used as the proxy destination in this proxy relationship. If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object is zero.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 8}; contextProxyContext ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ObjectIdentifier; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR contextProxyContextBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!If the value of the corresponding instance of the contextViewIndex is equal to zero, then the value of an instance of this object identifies the context of a proxy relationship. Interpretation of an instance of this object depends upon the value of the transport domain associated with the SNMPv2 party used as the proxy destination in this proxy relationship. If the value of the corresponding instance of the contextViewIndex is greater than zero, then the value of an instance of this object is { 0 0 }.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 9}; contextStorageType ATTRIBUTE DERIVED FROM storageType; BEHAVIOUR contextStorageTypeBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; LaBarre Expires November 29, 1993 Page 27 Draft ISO/CCITT and Internet Management Security 5/26/93 DESCRIPTION !!The storage type for this conceptual row in the contextTable.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 10}; contextStatus ATTRIBUTE DERIVED FROM {iimcManagementDocMan 1}:rowStatus; BEHAVIOUR contextStatusBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The status of this conceptual row in the contextTable. A context is not qualified for activation until instances of all corresponding columns have the appropriate value. In particular, if the context's contextViewIndex is greater than zero, then the viewStatus column of the associated conceptual row(s) in the viewTable must have the value `active'. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the contextStatus column is `notReady'.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 2 1 1 11}; partyAuthClock ATTRIBUTE DERIVED FROM clock; BEHAVIOUR partyAuthClockBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The authentication clock which represents the local notion of the current time specific to the party. This value must not be decremented unless the party's secret information is changed simultaneously, at which time the party's nonce and last-timestamp values must also be reset to zero, and the new value of the clock, respectively.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 8}; partyAuthLifetime ATTRIBUTE LaBarre Expires November 29, 1993 Page 28 Draft ISO/CCITT and Internet Management Security 5/26/93 WITH ATTRIBUTE SYNTAX IIMCPartyMIB.PartyAuthLifetime; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR partyAuthLifetimeBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The lifetime (in units of seconds) which represents an administrative upper bound on acceptable delivery delay for protocol messages generated by the party.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 11}; partyAuthPrivate ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.OctetString; MATCHES FOR EQUALITY, SUBSTRINGS; BEHAVIOUR partypartyAuthPrivateBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!If the value of partyAuthProtocol is {snmpv1CommString} then this attribute contains the community string to be used with SNMPv1 security. If the value of partyAuthProtocol is not {snmpv1CommString} then this attribute contains an encoding of the party's private authentication key which may be needed to support the authentication protocol. Although the value of this variable may be altered by a management operation (e.g., a SNMPv2 Set-Request), its value can never be retrieved by a management operation: when read, the value of this variable is the zero length OCTET STRING. The private authentication key is NOT directly represented by the value of this variable, but rather it is represented according to an encoding. This encoding is the bitwise exclusive-OR of the old key with the new key, i.e., of the old private authentication key (prior to the alteration) with the new private authentication key (after the alteration). Thus, when processing a received protocol Set operation, the new private authentication key is obtained from the value of this variable as the result of a bitwise exclusive-OR of the variable's value and the old private authentication key. In calculating the exclusive-OR, if the old key is shorter than the new LaBarre Expires November 29, 1993 Page 29 Draft ISO/CCITT and Internet Management Security 5/26/93 key, zero-valued padding is appended to the old key. If no value for the old key exists, a zero-length OCTET STRING is used in the calculation.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 9}; partyAuthProtocol ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ObjectIdentifier; MATCHES FOR EQUALITY; BEHAVIOUR partypartyAuthProtocolBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The authentication protocol by which all messages generated by the party are authenticated as to origin and integrity. In this context, the value { noAuth } signifies that messages generated by the party are not authenticated. The value {snmpv1CommString} indicates that SNMPv1 community string is to be used. The community string shall be present in partyAuthPrivate!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 7}; partyAuthPublic ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.OctetString; MATCHES FOR EQUALITY; BEHAVIOUR partyAuthPublicBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!A publicly-readable value for the party. Depending on the party's authentication protocol, this value may be needed to support the party's authentication protocol. Alternatively, it may be used by a manager during the procedure for altering secret information about a party. (For example, by altering the value of an instance of this object in the same SNMP Set-Request used to update an instance of partyAuthPrivate, a subsequent Get-Request can determine if the Set- Request was successful in the event that no response to the Set-Request is received, see RFC1446.) The length of the value is dependent on the LaBarre Expires November 29, 1993 Page 30 Draft ISO/CCITT and Internet Management Security 5/26/93 party's authentication protocol. If not used by the authentication protocol, it is recommended that agents support values of any length up to and including the length of the corresponding partyAuthPrivate object.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 10}; partyCloneFrom ATTRIBUTE DERIVED FROM party; BEHAVIOUR partyCloneFromBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The identity of a party to clone authentication and privacy parameters from. When read, the value { 0 0 } is returned. This value can only be written when the associated instance of partyStatus either does not exist or has the value `notReady'. When written, the value identifies a party, the cloning party, whose status column has the value `active'. The cloning party is used in two ways. One, if instances of the following objects do not exist for the party being created, then they are created with values identical to those of the corresponding objects for the cloning party: partyAuthProtocol partyAuthPublic partyAuthLifetime partyPrivProtocol partyPrivPublic Two, instances of the following objects are updated using the corresponding values of the cloning party: partyAuthPrivate partyPrivPrivate (e.g., the value of the cloning party's instance of the partyAuthPrivate object is XOR'd with the value of the partyAuthPrivate instances of the party being created.)!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 15}; partyIdentity ATTRIBUTE LaBarre Expires November 29, 1993 Page 31 Draft ISO/CCITT and Internet Management Security 5/26/93 DERIVED FROM party; BEHAVIOUR partyIdentityBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!A party identifier uniquely identifying a particular SNMP party.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 1}; partyIndex ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.Index; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR partyIndexBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!A unique value for each SNMPv2 party. The value for each SNMPv2 party must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 2}; partyLocal ATTRIBUTE DERIVED FROM {iimcManagementDocMan 1}:truthValue; BEHAVIOUR partyLocalBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!An indication of whether this party executes at this SNMPv2 entity. If this object has a value of true(1), then the SNMPv2 entity will listen for SNMPv2 messages on the partyTAddress associated with this party. If this object has the value false(2), then the SNMPv2 entity will not listen for SNMPv2 messages on the partyTAddress associated with this party.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 6}; partyMaxMessageSize ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.PartyMaxMessageSize; LaBarre Expires November 29, 1993 Page 32 Draft ISO/CCITT and Internet Management Security 5/26/93 MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR partyMaxMessageSizeBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The maximum length in octets of a SNMP message which this party will accept. For parties which execute at an agent, the agent initializes this object to the maximum length supported by the agent, and does not let the object be set to any larger value. For parties which do not execute at the agent, the agent must allow the manager to set this object to any legal value, even if it is larger than the agent can generate.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 5}; partyPrivProtocol ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ObjectIdentifier; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR partyPrivProtocolBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The privacy protocol by which all protocol messages received by the party are protected from disclosure. In this context, the value { noPriv } signifies that messages received by the party are not protected.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 12}; partyPrivPrivate ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.OctetString; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR partyPrivPrivateBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!An encoding of the party's private encryption key which may be needed to support the privacy protocol. Although the value of this variable may be altered by a management operation (e.g., a SNMPv2 Set-Request), its value can never be retrieved by a management operation: when read, LaBarre Expires November 29, 1993 Page 33 Draft ISO/CCITT and Internet Management Security 5/26/93 the value of this variable is the zero length OCTET STRING. The private encryption key is NOT directly represented by the value of this variable, but rather it is represented according to an encoding. This encoding is the bitwise exclusive-OR of the old key with the new key, i.e., of the old private encryption key (prior to the alteration) with the new private encryption key (after the alteration). Thus, when processing a received protocol Set operation, the new private encryption key is obtained from the value of this variable as the result of a bitwise exclusive-OR of the variable's value and the old private encryption key. In calculating the exclusive-OR, if the old key is shorter than the new key, zero-valued padding is appended to the old key. If no value for the old key exists, a zero-length OCTET STRING is used in the calculation.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 13}; partyPrivPublic ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.OctetString; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR partyPrivPublicBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!A publicly-readable value for the party. Depending on the party's privacy protocol, this value may be needed to support the party's privacy protocol. Alternatively, it may be used by a manager as a part of its procedure for altering secret information about a party. (For example, by altering the value of an instance of this object in the same SNMP Set-Request used to update an instance of partyPrivPrivate, a subsequent Get-Request can determine if the Set-Request was successful in the event that no response to the Set-Request is received, see RFC 1446.) The length of the value is dependent on the party's privacy protocol. If not used by the privacy protocol, it is recommended that agents support values of any length up to and including the length of the corresponding partyPrivPrivate object.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 14}; LaBarre Expires November 29, 1993 Page 34 Draft ISO/CCITT and Internet Management Security 5/26/93 partyStatus ATTRIBUTE DERIVED FROM {iimcManagementDocMan 1}:rowStatus; BEHAVIOUR partyStatusBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The status of this conceptual row in the partyTable. A party is not qualified for activation until instances of all columns of its partyEntry row have an appropriate value. In particular: A value must be written to the Party's partyCloneFrom object. If the Party's partyAuthProtocol object has the value md5AuthProtocol, then the corresponding instance of partyAuthPrivate must contain a secret of the appropriate length. Further, at least one management protocol set operation updating the value of the party's partyAuthPrivate object must be successfully processed, before the partyAuthPrivate column is considered appropriately configured. If the Party's partyPrivProtocol object has the value desPrivProtocol, then the corresponding instance of partyPrivPrivate must contain a secret of the appropriate length. Further, at least one management protocol set operation updating the value of the party's partyPrivPrivate object must be successfully processed, before the partyPrivPrivate column is considered appropriately configured. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the partyStatus column is `notReady'.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 17}; partyStorageType ATTRIBUTE DERIVED FROM storageType; BEHAVIOUR partyStorageTypeBehaviour BEHAVIOUR DEFINED AS LaBarre Expires November 29, 1993 Page 35 Draft ISO/CCITT and Internet Management Security 5/26/93 !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The storage type for this conceptual row in the partyTable.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 16}; partyTAddress ATTRIBUTE DERIVED FROM tAddress; BEHAVIOUR partyTAddressBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The transport service address by which the party receives network management traffic, formatted according to the corresponding value of partyTDomain. For rfc1351Domain, partyTAddress is formatted as a 4-octet IP Address concatenated with a 2-octet UDP port number.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 4}; partyTDomain ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ObjectIdentifier; MATCHES FOR EQUALITY; BEHAVIOUR partyTDomainBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!Indicates the kind of transport service by which the party receives network management traffic. An example of a transport domain is 'rfc1351Domain' (SNMP over UDP).!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 1 1 1 3}; viewIndex ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.Index; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR viewIndexBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; LaBarre Expires November 29, 1993 Page 36 Draft ISO/CCITT and Internet Management Security 5/26/93 DESCRIPTION !!A unique value for each MIB view. The value for each MIB view must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 4 1 1 1}; viewMask ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ViewMask; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR viewMaskBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The bit mask which, in combination with the corresponding instance of viewSubtree, defines a family of view subtrees. Each bit of this bit mask corresponds to a sub- identifier of viewSubtree, with the most significant bit of the i-th octet of this octet string value (extended if necessary, see below) corresponding to the (8*i - 7)-th sub-identifier, and the least significant bit of the i-th octet of this octet string corresponding to the (8*i)-th sub-identifier, where i is in the range 1 through 16. Each bit of this bit mask specifies whether or not the corresponding sub-identifiers must match when determining if an OBJECT IDENTIFIER is in this family of view subtrees; a '1' indicates that an exact match must occur; a '0' indicates 'wild card', i.e., any sub-identifier value matches. Thus, the OBJECT IDENTIFIER X of an object instance is contained in a family of view subtrees if the following criteria are met: for each sub-identifier of the value of viewSubtree, either: the i-th bit of viewMask is 0, or the i-th sub-identifier of X is equal to the i-th sub-identifier of the value of viewSubtree. If the value of this bit mask is M bits long and there are more than M sub-identifiers in the corresponding instance of viewSubtree, then the LaBarre Expires November 29, 1993 Page 37 Draft ISO/CCITT and Internet Management Security 5/26/93 bit mask is extended with 1's to be the required length. Note that when the value of this object is the zero-length string, this extension rule results in a mask of all-1's being used (i.e., no 'wild card'), and the family of view subtrees is the one view subtree uniquely identified by the corresponding instance of viewSubtree.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 4 1 1 3}; viewStatus ATTRIBUTE DERIVED FROM (iimcManagementDocMan 1}:rowStatus; BEHAVIOUR viewStatusBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The status of this conceptual row in the viewTable.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 4 1 1 6}; viewStorageType ATTRIBUTE DERIVED FROM storageType; BEHAVIOUR viewStorageTypeBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The storage type for this conceptual row in the viewTable.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 4 1 1 5}; viewSubtree ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ObjectIdentifier; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR viewSubtreeBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!A MIB subtree.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 4 1 1 2}; LaBarre Expires November 29, 1993 Page 38 Draft ISO/CCITT and Internet Management Security 5/26/93 viewType ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ViewType; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR viewTypeBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the object type defined in [RFC1447] by the same name.!!; DESCRIPTION !!The status of a particular family of view subtrees within the particular SNMPv2 context's MIB view. The value 'included(1)' indicates that the corresponding instances of viewSubtree and viewMask define a family of view subtrees included in the MIB view. The value 'excluded(2)' indicates that the corresponding instances of viewSubtree and viewMask define a family of view subtrees excluded from the MIB view.!!; ENDPARSE!;; REGISTERED AS {iimcAutoTrans 1 3 6 1 6 3 3 2 4 1 1 4}; -- 4.1.3 Party MIB Name Bindings aclEntry-aclTableNB NAME BINDING SUBORDINATE OBJECT CLASS aclEntry AND SUBCLASSES ; NAMED BY SUPERIOR OBJECT CLASS aclTable AND SUBCLASSES; WITH ATTRIBUTE {iimcManagementDocMan 1}: internetClassId; BEHAVIOUR aclEntry-aclTableNBBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE INDEX aclSubject, aclTarget, aclResources; CREATEDELETEATT aclStatus; CREATEDELETEVALUE SNMPV2ROWSTATUS; ENDPARSE!;; CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE-OBJECT; DELETE DELETES-CONTAINED-OBJECTS; REGISTERED AS {iimcManagementNB 1 3 6 1 6 3 3 2 3 1 1}; aclTable-systemNB NAME BINDING SUBORDINATE OBJECT CLASS aclTable AND SUBCLASSES ; NAMED BY SUPERIOR OBJECT CLASS "Rec. X.721 | ISO/IEC 10165-2 : 1992":system AND SUBCLASSES; WITH ATTRIBUTE {iimcManagementDocMan 1}: internetClassId; LaBarre Expires November 29, 1993 Page 39 Draft ISO/CCITT and Internet Management Security 5/26/93 CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE-OBJECT; DELETE DELETES-CONTAINED-OBJECTS; REGISTERED AS {iimcManagementNB 1 3 6 1 6 3 3 2 3 1}; contextEntry-contextTableNB NAME BINDING SUBORDINATE OBJECT CLASS contextEntry AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS contextTable AND SUBCLASSES; WITH ATTRIBUTE {iimcManagementDocMan 1}: internetClassId; BEHAVIOUR contextEntry-contextTableNBBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE INDEX contextIdentity; CREATEDELETEATT contextStatus; CREATEDELETEVALUE SNMPV2ROWSTATUS; ENDPARSE!;; CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE-OBJECT; DELETE DELETES-CONTAINED-OBJECTS; REGISTERED AS {iimcManagementNB 1 3 6 1 6 3 3 2 2 1 1}; contextTable-systemNB NAME BINDING SUBORDINATE OBJECT CLASS contextTable AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS "Rec. X.721 | ISO/IEC 10165-2 : 1992" :system AND SUBCLASSES; WITH ATTRIBUTE {iimcManagementDocMan 1}: internetClassId; CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE-OBJECT; DELETE DELETES-CONTAINED-OBJECTS; REGISTERED AS {iimcManagementNB 1 3 6 1 6 3 3 2 2 1}; partyEntry-partyTableNB NAME BINDING SUBORDINATE OBJECT CLASS partyEntry AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS partyTable AND SUBCLASSES; WITH ATTRIBUTE {iimcManagementDocMan 1}: internetClassId; BEHAVIOUR partyEntry-partyTableNBBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE INDEX partyIdentity; CREATEDELETEATT partyStatus; CREATEDELETEVALUE SNMPV2ROWSTATUS; ENDPARSE!;; LaBarre Expires November 29, 1993 Page 40 Draft ISO/CCITT and Internet Management Security 5/26/93 CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE-OBJECT; DELETE DELETES-CONTAINED-OBJECTS; REGISTERED AS {iimcManagementNB 1 3 6 1 6 3 3 2 1 1 1}; partyTable-systemNB NAME BINDING SUBORDINATE OBJECT CLASS partyTable AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS "Rec. X.721 | ISO/IEC 10165-2 : 1992" :system AND SUBCLASSES; WITH ATTRIBUTE {iimcManagementDocMan 1}: internetClassId; CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE-OBJECT; DELETE DELETES-CONTAINED-OBJECTS; REGISTERED AS {iimcManagementNB 1 3 6 1 6 3 3 2 1 1}; viewEntry-viewTableNB NAME BINDING SUBORDINATE OBJECT CLASS viewEntry AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS viewTable AND SUBCLASSES; WITH ATTRIBUTE {iimcManagementDocMan 1}: internetClassId; viewEntry-viewTableNBBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE INDEX viewIndex, viewSubtree; CREATEDELETEATT viewStatus; CREATEDELETEVALUE SNMPV2ROWSTATUS; ENDPARSE!;; CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE-OBJECT; DELETE DELETES-CONTAINED-OBJECTS; REGISTERED AS {iimcManagementNB 1 3 6 1 6 3 3 2 4 1 1}; viewTable-systemNB NAME BINDING SUBORDINATE OBJECT CLASS viewTable AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS "Rec. X.721 | ISO/IEC 10165-2 : 1992" :system AND SUBCLASSES; WITH ATTRIBUTE {iimcManagementDocMan 1}: internetClassId; CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE-OBJECT; DELETE DELETES-CONTAINED-OBJECTS; REGISTERED AS {iimcManagementNB 1 3 6 1 6 3 3 2 4 1}; -- 4.1.4 Party MIB Attribute Types LaBarre Expires November 29, 1993 Page 41 Draft ISO/CCITT and Internet Management Security 5/26/93 party ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ObjectIdentifier; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR partyBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the type defined in [RFC1447] by the same name.!!; DESCRIPTION !!Denotes a SNMPv2 party identifier. Note that agents may impose implementation limitations on the length of OIDs used to identify Parties. As such, management stations creating new parties should be aware that using an excessively long OID may result in the agent refusing to perform the set operation and instead returning the appropriate error response, e.g., noCreation.!!; ENDPARSE!;;; tAddress ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.OctetString; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR tAddressBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the type defined in [RFC1447] by the same name.!!; DESCRIPTION !!Denotes a transport service address. For snmpUDPDomain, a TAddress is 6 octets long, the initial 4 octets containing the IP-address in network-byte order and the last 2 containing the UDP port in network-byte order. Consult [RFC1448] for further information on snmpUDPDomain.!!; ENDPARSE!;;; clock ATTRIBUTE DERIVED FROM {iimcManagementDocMan 1}:clock; BEHAVIOUR clockBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the type defined in [RFC1447] by the same name.!!; DESCRIPTION !!A party's authentication clock - a non-negative integer which is incremented as specified/allowed by the party's Authentication Protocol. For noAuth, a party's authentication clock is unused and its value is undefined. LaBarre Expires November 29, 1993 Page 42 Draft ISO/CCITT and Internet Management Security 5/26/93 For v2md5AuthProtocol, a party's authentication clock is a relative clock with 1-second granularity.!!; ENDPARSE!;;; context ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.ObjectIdentifier; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR contextBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the type defined in [RFC1447] by the same name.!!; DESCRIPTION !!Denotes a SNMPv2 context identifier. Note that agents may impose implementation limitations on the length of OIDs used to identify Parties. As such, management stations creating new parties should be aware that using an excessively long OID may result in the agent refusing to perform the set operation and instead returning the appropriate error response, e.g., noCreation.!!; ENDPARSE!;;; storageType ATTRIBUTE WITH ATTRIBUTE SYNTAX IIMCPartyMIB.StorageType; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR storageTypeBehaviour BEHAVIOUR DEFINED AS !BEGINPARSE REFERENCE !!This corresponds to the type defined in [RFC1447] by the same name.!!; DESCRIPTION !!Describes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is nonVolatile(3) is backed up by stable storage. A row which is permanent(4) cannot be changed nor deleted.!!; ENDPARSE!;;; 4.2 Party MIB ASN.1 Modules IIMCPartyMIB {iimcManagementModMan 3} DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS UInteger32, snmpv2, MODULE-IDENTITY LaBarre Expires November 29, 1993 Page 43 Draft ISO/CCITT and Internet Management Security 5/26/93 FROM SNMPv2-SMI partyAdmin, partyProtocols, noAuth, desPrivProtocol, v2md5AuthProtocol, temporalDomains, currentTime, restartTime, cacheTime, initialPartyId, initialContextId FROM SNMPv2-Party-MIB snmpUDPDomain FROM SNMPv2-TM iimcManagementDocMan, iimcManagementModMan, iimcAutoTrans, iimcManagementNB, FROM IimcAssignedOIDs {iimcManagementModMan 1}; -- The following registration identifier is assigned to this -- document using procedures defined in [IIMCIMIBTRANS]: iimcIIMCSEC OBJECT IDENTIFIER ::={iimcManagementDocMan 4} -- Generic syntax Integer ::= INTEGER OctetString ::= OCTET STRING ObjectIdentifier ::= OBJECT IDENTIFIER -- MIB specific syntax AclPrivileges ::= INTEGER (0..255) Clock ::= UInteger32 Index ::= INTEGER (1..65535) PartyAuthLifetime ::= INTEGER (0..2147483647) PartyMaxMessageSize ::= INTEGER (484..65507) StorageType ::= INTEGER { other(1), -- eh? volatile(2), -- e.g., in RAM nonVolatile(3), -- e.g., in NVRAM permanent(4) -- e.g., in ROM } ViewMask ::= OCTET STRING (SIZE (0..16)) ViewType ::= INTEGER { included(1), excluded(2) } LaBarre Expires November 29, 1993 Page 44 Draft ISO/CCITT and Internet Management Security 5/26/93 -- Default value constants c-aclPrivileges INTEGER ::= 35 c-contextLocal BOOLEAN ::= TRUE c-DEFAULTNullString OCTET STRING ::= ''H c-contextLocalTime Clock ::= currentTime c-DEFAULTStorageType INTEGER ::= 3 c-partyTDomain OBJECT IDENTIFIER ::= snmpUDPDomain c-partyTAddress OCTET STRING ::= '000000000000'H c-partyMaxMessageSize INTEGER ::= 484 c-partyLocal BOOLEAN ::= FALSE c-partyAuthProtocol OBJECT IDENTIFIER ::= v2md5AuthProtocol c-partyAuthClock INTEGER ::= 0 c-partyAuthLifetime INTEGER ::= 300 c-partyPrivProtocol OBJECT IDENTIFIER ::= noPriv c-viewType INTEGER ::= 1 END 5. Acknowledgments The following individuals have contributed to this effort. Bob Aronoff - NIST Jon Biggar - NetLabs Mary Brady - NIST April Chang - NetLabs Ken Chapman - Stratus Computer Inc. Alice Chen - Boeing Christopher Crowell - Cabletron Systems Jock Embry - Opening Technologies Ian Emsley - Bull S.A Paul Golick - IBM Ulrich Gremmelmaier - University of Stuttgart Pramod Kalyanasundaram - University of Delaware Ken Hunter - Hewlett-Packard Lee LaBarre - The MITRE Corporation David Liu - Northern Telecom Jim MacLeod - U S West Reece Markowsky - OSIWare Subrata Mazumdar - IBM Keith McCloghrie - Hughes LAN Systems Owen Newnan - U S West Steve Ng - MPR Teltech Yasuhiro Ohara - NTT Jong-Tae Park - KyungPook National University George Pavlou - University College of London Lisa Phifer - Bellcore Jim Reilly - Technical Rsch Ctr of Finland Tom Rutt - AT&T Adarsh Sethi - University of Delaware Raj Sirsikar - University of Delaware Baltej Singh - OSIWare LaBarre Expires November 29, 1993 Page 45 Draft ISO/CCITT and Internet Management Security 5/26/93 Mark Smith - Hewlett-Packard Einar Stefferud - Network Management Associates Mark Sylor - Digital Hector Trevino - Bellcore Huy Truong - Tandem Al Vincent - U S West Dean Voiss - NetLabs David Waitzman - BBN Graham Wisdom - Timeplex Yoshi Yamashita - NKK Corporation LaBarre Expires November 29, 1993 Page 46 Draft ISO/CCITT and Internet Management Security 5/26/93 References [ISO7498-4] ISO/IEC IS 7498-4, Information Processing Systems - Open Systems Interconnection -Basic Reference Model Part 4 - Management Framework, 1989. [ISO8824] ISO/IEC 8824: Information Technology - Open System Interconnection - Specification of Abstract Syntax Notation One (ASN.1),1990. [ISO8825] ISO/IEC 8825: Information Technology - Open System Interconnection-Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1),1990. [ISO9594] ISO/IEC 9594, Information Technology - Open System Interconnection - The Directory - Parts 1-8. [ISO9595] ISO/IEC 9595, Information Technology - Open System Interconnection - Common Management Information Service Definition, 1991. [ISO9596-1] ISO/IEC 9596-1, Information Technology - Open Systems Interconnection - Common Management Information Protocol - Part 1: Specification, 1991. [ISO10164-9] ISO DIS 10164-9, Information Processing Systems - Open Systems Interconnection - Structure of Management Information - Part 9: Objects and Attributes for Access Control, ISO/IEC JTC1/SC21/N7661, March, 1993. [ISO10165-1] ISO/IEC 10165-1: Information Technology - Open Systems Interconnection - Structure of Management Information - Part 1: Management Information Model, 1991. [ISO10165-2] ISO/IEC 10165-2: Information Technology - Open Systems Interconnection - Structure of Management Information - Part 2: Definition of Management Information, 1992. [ISO10165-4] ISO/IEC 10165-4: Information Technology - Open Systems Interconnection - Structure of Management Information - Part 4: Guidelines for the Definition of Managed Objects, 1991. [ISO10181-3] ISO/IEC DIS 10181-3, Information Technology , OSI Security Model, Part 3: Access Control Framework, 1993. [ISO11586-1] ISO/IEC CD 11586-1, Information Technology - Generic Upper Layers Security - Part 1: Overview, Models and Notation, November 1992. [ISO11586-2] ISO/IEC CD 11586-2, Information Technology - Generic Upper Layers Security - Part 2: Security Exchange Service Element(SESE) Service Definition, November 1992. [ISO11586-3] ISO/IEC CD 11586-3, Information Technology -Generic LaBarre Expires November 29, 1993 Page 47 Draft ISO/CCITT and Internet Management Security 5/26/93 Upper Layers Security - Part 3: Security Exchange Service Element(SESE) Protocol Specification, November 1992. [ISO11586-4] ISO/IEC CD 11586-4, Information Technology - Generic Upper Layers Security - Part 4: Protecting Transfer Syntax Specification, November 1992. [RFC1155] RFC1155, M. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP based internets, May 1990. [RFC1157] RFC1157, J.D. Case, M.S. Fedor, M.L. Schoffstall,C. Davin, Simple Network Management Protocol (SNMP), May 1990. [RFC1212] RFC1212, M. Rose, K. McCloghrie - Editors, Concise MIB Definitions, March 1991. [RFC1213] RFC1213, K. McCloghrie and M. Rose - Editors, Management Information Base for Network Management of TCP/IP- basedinternets: MIB-II, March 1991. [RFC1441] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser, Introduction to version 2 of the Internet-standard Network Management Framework, April 1993. [RFC1442] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser, Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. [RFC1445] J.R. Davin, J.M. Galvin, K.McCloghrie, Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. [RFC1446] J.M. Galvin, K. McCloghrie, J.R. Davin, Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. [RFC1447] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. [RFC1448] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser, Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993. [RFC1452] J.D. Case, K. McCloghrie, M.T. Rose, S.L.Waldbusser, Coexistence between version 1 and version 2 of the Internet Network Management Framework, April 1993. [IIMCIMIBTRANS] ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet MIBs to ISO/CCITT GDMO MIBs, Draft 2, May 1993. [IIMCMIB-II] ISO/CCITT and Internet Management Coexistence LaBarre Expires November 29, 1993 Page 48 Draft ISO/CCITT and Internet Management Security 5/26/93 (IIMC): Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO MIB, Draft 2, May 1993. [IIMCPROXY] ISO/CCITT and Internet Management Coexistence (IIMC): ISO/CCITT to Internet Management Proxy, Draft 2, May 1993. [IIMCOMIBTRANS] ISO/CCITT and Internet Management Coexistence (IIMC): Translation of ISO/CCITT GDMO MIBs to Internet MIBs, Draft 2, May 1993. [NMF016] Network Management Forum: Forum 016, Application Services: Security of Management, Issue 1.0, August, 1992. [NMFTR107] NM Forum and X/Open, ISO/CCITT and Internet Management: Coexistence and Interworking Strategy, Issue 1.0, October, 1992. [ECMA138] ECMA-138, Security in Open Systems: Data Elements and Service Definitions, December 1989. LaBarre Expires November 29, 1993 Page 49 Draft ISO/CCITT and Internet Management Security 5/26/93 Appendix A (Normative) Managed Object Conformance Statements (MOCS) Editor's Note: [This section will be filled in prior to publication. When completed, this section will contain a tabular representation of the managed object classes, attributes, notifications, and name bindings defined in this document. The format of these proforma tables will be as defined by ISO/IEC 10165-6.] INTERNET DRAFT - Expires November 29, 1993 LaBarre Expires November 29, 1993 Page 50